Language/OS - Multiplatform Resource Library/LANGUAGE OS.iso/gnu/uucp-104.lha/uucp-1.04/TODO

Text File | 1993-02-13 | 18KB | 574 lines

This is a list of things to do for the Taylor UUCP package.  Please
feel free to work on any of them.  You may want to check with me first
to make sure that nobody else is working on them as well.

Some of these are my thoughts, but most are suggestions from other
people; I have tried to give credit.  They are in the order I received
them; the missing numbers have already been implemented.

Just because something is on the list doesn't mean that I necessarily
think it is a good idea.  It does mean that I think it's worth
thinking about.

2.

John Cowan <[e-mail]> says:

>I think you should accept a broader range of time specifications.
>Consider using getdate() (from your handy Usenet news source code)
>with its high-powered yacc parser.

Of course, getdate() accepts a single date, but we want a range.  A
better syntax would be certainly be nice.

9.

Gordon Burditt <[e-mail]> warns about modifications
to the TZ environment variable, to fool uucico into dialing out at an
inappropriate time.

10.

Gordon Burditt <[e-mail]> says:

>(4) Less important, because few people will have this problem, is a
>port-specific dialcodes file.  Why?  Well, one system I had was connected
>to 2 inside lines "dial 9 for outside line", and one outside line (which
>doesn't want the 9).  A number of the systems called were "inside", so
>you didn't add the 9 on those lines dialing from inside, but you did add
>"390" to the 4-digit number if you dialed it via "outside".  Also not
>unheard of are systems with 2 outside lines that are local to different
>area codes, or one local outside line and one WATS line (which MUST
>have an area code).
>Example:
>    inside-line Dialcodes        outside-line Dialcodes
>    pbx    ""            pbx    "390"
>    local    "9"            local    ""
>    nyc    "9-1212"        nyc    "1212"

12.

Ralf E. Stranzenbach <[e-mail]> says:

>It would be nice to also have the option of running a shell script each time
>uucico connects/disconnects a systen. I do not mean shell scripts for dial/in.
>I would like to do some accounting and batching when the connection
>establishes.

13.

[e-mail] (Leslie Mikesell) writes:

>>local-send /usr/spool/uucppublic !/usr/spool/uucpublic/private
>>
>>The directories are searched from left to right, and the last one to
>>match determines whether the file may be sent or not.  This is
>>slightly more general than NOWRITE, since it permits a public
>>directory within a private directory within a public directory,
>>although probably nobody will ever want that.
>
>Interesting... The obvious enhancement is to generalize to shell-like
>wild cards for the READ/WRITE/COMMANDS entries.

14.

Should there be a way for chat scripts to specify the parity to
generate?  I don't think there's much point to specifying what parity
to accept.

17.

The -b and -s switches to uux are not implemented by uuxqt.

18.

If we are supposed to call a system back, we should do it immediately
rather than merely queuing up an empty command file.

22.

Add an ftp port type which uses anonymous ftp rather than any of the
UUCP protocols to do file transfers.  This would allow ftp work to be
done late at night, and allow neighbors of cooperative Internet sites
to use UUCP forwarding for anonymous FTP.

31.

David Nugent: add a -C option to uucico to only call the system if
there is work to do.

32.

It would be nice if uucico could sleep until a line was available.
This is complicated by the possibility of wanting to wait for any of
several different lines, and one would really want some sort of
semaphore function to do it right.  If the available lines could be
sorted, then each could be assigned to a byte in a line lock file.
Looking for a line could be done by sleeping on a read lock on all
possible lines.  Once it came through, write locks would be attempted.
If they all failed, somebody else snuck in, so you would sleep on a
read lock again.  This isn't great because a process could be starved,
but it might be better than nothing.

This could be tied in to uucp and uux, such that they wouldn't
actually fire up uucico unless a line was known to be available; an
additional switch would be used to fire up uucico anyhow (or one could
switch the default behaviour and the switch).

So how do you sort the lines?  You could just use the index in the
port (or Devices) file, but what if multiple ports used the same
physical device?  Hmmm.

43.

David Nugent: it would be nice to be able to set debugging, log, and
statistics files on a site by site basis.
Brian Murrell: heck, set those files on a port by port basis as well.

74.

Yanek Martinson: allow each system to independently choose whether to
permit shell execution.

81.

Marty Shannon: log reason for dial failure (chat-fail string) in
.Status file.

83.

Switch between 'M' and 'S' correctly in the BNU log file output.

86.

Les Mikesell: allow a separate program to be specified to handle the
communications with a particular system.

105.

T. William Wells: close and open the Debug file after each file
transfer.  Alternatively, cycle through a series of Debug file names
every 1000 lines or so.

106.

Marty Shannon: add a time command for ports, to specify when they may
be used.

115.

T. William Wells: new options for uustat:
    -i display job ids only
Also, there should perhaps be a configuration option to request uustat
to only display jobs submitted by the user running uustat, except for
root and uucp.

117.

Marc Unangst: provide some way to change the debugging level of a
running uucico.  T. William Wells suggests having it read a file to
change arbitrary configuration information, although obviously one has
to be careful of what gets changed while a connection is active.

120.

Jarmo Raiha: new chat-fail commands: one to not update the status file
and require a retry wait, and one to permit the string to occur a few
times before reporting an error.

124.

Peter da Silva: perhaps there should be a ``chat-end-program'' command
to let a program be run after the initial handshake has been completed
and the protocol has been selected and turned on.  This would let
people run stty to change their terminal parameters.

128.

Richard Stallman: have an interactive program to set up a chat script.
It would let you type directly to the port, recording what you type as
send strings and recording what comes back from the other side as
expect strings.

129.

Use POSIX fcntl locks when possible instead of creating a lock file.

130.

Chip Salzenberg: BSD lets you override the timeout for a particular
expect string by using a trailing ~.

138.

T. William Wells: BNU apparently uses a file named A.whatever to hold
the line number reached in current C. file processing.  This is a
hack, and won't work right with size control anyhow, but
fsysdep_did_work could, for example, clobber the first byte in the
line to a # or something to mark that it had been finished.  Still a
hack, but a better one.

139.

Patrick Smith: incorporate patches to generate full debugging traces
with less debugging file overhead.  The debugging file repeats too
much information at great length right now--not good.

141.

Franc,ois Pinard: batch up pauses and delays in chat scripts and do
them all at once in a single system call.  This is particularly useful
for pauses on systems which don't support subsecond sleeps.  For
everything else it's a fairly minor optimization.

142.

Franc,ois Pinard: give uustat an option to requeue jobs to another
system.  This only makes a lot of sense for rmail executions, but it's
fairly easy to do for any type of command.  I think uucico does all
the file checking needed to ensure that this doesn't break security,
but that should be double-checked.

144.

T. William Wells: add a -g option to uucico to permit specifying the
maximum grade to be transferred at that time.  This could restrict the
timegrade command further, but should not be permitted to override it.

145.

T. William Wells: if uucico or uuxqt get started with bad arguments,
put an indication in the log file since stderr may be /dev/null.

146.

Richard Todd: it would be nice to sometimes be able to request the
other side to turn on debugging.

147.

Bart Schaefer: some more possible options for uucico:
    -R reverse roles (hangup immediately).  Not too exciting.
    some method to restrict calling to particular systems.

148.

Jarmo Raiha: some method to control the work queue at the remote end.
This could get awfully general, though.

149.

The interaction of the time command and defaults can be confusing,
since any time command in the actual system entry, even a fairly
specific one, will wipe out the default entry.  Not sure what can be
done about this.

150.

Jarmo Raiha: should there be some way to specify modem initialization
strings when uucico is hanging on a port with -l or -e?  This would
presumably require a new type of chat script associated with a dialer.

151.

Petri Helenius: log complete CONNECT string reported by modem, so that
the baud rate is recorded in the log file.

152.

Marc Evans: let the protocol selection be based on the CONNECT string,
so that different protocols could be selected based on what type of
connection was made.

153.

Chris Lewis: provide a signal to get a core dump even on systems which
won't do core dumps if the uid is not the euid.  One could catch a
signal, call setuid (getuid ()), and then raise the signal again.
Unfortunately the core dump has to wind up in a directory which is
world writable, so that the process is able to create the core file,
but is not world readable, since that would permit anybody to read the
core dump file and extract private information from it.

154.

Les Mikesell: write a new version of dial.o, with provisions for
running a chat script.

155.

Scott Blachowicz: perhaps there should be some way to telling uucico
to not log certain errors.  This could get fairly complex, though.

156.

Franc,ois Pinard: have uustat -m report the time of the last
successful conversation when reporting a failure.

158.

Thomas Fischer: should there be a way to completely disable an entry
in the sys, port or dial file?  Such as a ``disable'' command?

159.

Petri Helenius: when uuxqt -s is invoked, lock uuxqt for the system so
that only one uuxqt is invoked per system.  If the -c option is used,
don't lock on a per system basis, and ignore any per system locks
(regardless of -s).  If neither option is used, respect existing
system and command locks, and do any other type of file.

161.

Scott Blachowicz: provide some sort of include mechanism for the
configuration files.

162.

Chris Lewis: add uuxqtpolicy command, probably in config, supporting
the following values which determine when uuxqt should be run:
    - never (let cron or something else worry about it)
    - perinvocation (when uucico exits for good - current behaviour)
    - persite (when uucico terminates a conversation - HDBish)
    - periodic (per 5 or 10 incoming X. files - BSDish)
    - perturnaround?

163.

Sort jobs in the send queue by size.  Pretty easy.

164.

Ed Carp: preserve files if uuxqt execution fails.

165.

Marc Sheldon: use exit codes from <sysexits.h> in uux and uucp.

166.

Chip Salzenberg: allow chat failure strings to specify a retry time.

167.

Gregory Bond: allow a dialer sequence for a TCP port, so you can make
a TCP connection to a modem and then dial out.

168.

Jose A. Manas: allow a maximum connect time, after which we try to
hang up the connection.  This requires a protocol extension, since
there's no way to force the other side to hang up.  The best we can do
without an extension is refuse to send any new jobs ourselves.  Of
course, we could just drop the connection.

169.

Franc,ois Pinard: when given uustat -k00FC, check each possible job ID
and use it if there is an unambiguous one.

170.

T. William Wells: if ! HAVE_SETREUID && ! HAVE_SAVED_SETUID, fork a
subprocesses to revoke setuid and read the file over a pipe.

171.

Provide some option to have the internal uuconf functions not start
with an underscore.

172.

T. William Wells: have some way to configure the parity for cu.

173.

Gert Doering: uuchk should display unknown system information.

175.

T. William Wells:
Cu will not let itself be interrupted before the connection is
established. If the chat script doesn't write something, cu does
something odd, I've forgotten exactly what. Cu takes an
inordinate amount of time after the line drops to exit. Somebody,
cu, I think, but maybe uucico, drops dtr twice sometimes. Again,
somebody will attempt to write after a hangup signal has been
received. Once a hangup has been received, I/O should not be
attempted. Among other things this will save the bacon of those
who have brain damaged serial drivers (FAS, sigh, is among them)
that don't handle output properly on a dropped line.

Me:
Note that sometimes you do want to write to a line after receiving a
hangup signal.  For example, you might want to use ATZ to reset a
modem.

176.

Hans-Dieter Doll: provide some way (another escape sequence) to pass
the protocol to a chat-program.  Or, allow the protocol as an argument
to the chat script command, which is more general, but maybe a bit too
fancy.

177.

Nickolay Saukh: use a default port for cu, you can just do ``cu
number''.

178.

Don Phillips: should there be some way to restrict of grade of
transfers even when the other system places the call?

179.

Nickolay Saukh: add something to chat scripts to specify the timeout
for an expect string, e.g. AT\c OK\W3 to wait for 3 seconds.  Except
that perhaps the unit should not be seconds.  Berkeley apparently uses
~number, not \W number, but I don't see any reason to prevent use of
the ~ character in an expect string.

180.

Nickolay Saukh: if we have received a partial file, request the remote
system to start sending from that point.  We currently accept SVR4
style remote file positioning requests, but we do not generate them.

181.

Mark Powell: provide some way to restrict file transfer by size as
well as grade?  One way would be to let uux select the grade based on
the file size.

182.

Mark Powell: permit using multiple timetables in a single time
statement.

183.

Optionally check for interrupts in fcopy_file, since it can take a
long time to copy a file named in a uucp request.

184.

Ian Moran: if an attempt is made to a copy a file to a directory which
denies write permission, perhaps the file should be saved somewhere.
It must be saved in a private location, though.

185.

A syntax error in a command received from the remote system should not
hold up the queue.  Unfortunately, I don't know what can be done
except deny the command and report it.  Reporting a garbled command
error should report the command correctly, rather than just the first
character.

186.

Franc,ois Pinard: have an option to control nostop vs. stop on the cu
command line.

187.

Fix the notion of %nostop to be SVID compatible.

188.

Frank Conrad: provide a means to set the strip mode for a port, to
make it easy to use it from cu.

189.

Marc Unangst: there should be a way to specify that a system should
only be called if there are jobs of a certain grade, but if the system
is called then jobs of any grade should be transferred.  This
basically means splitting the ``timegrade'' command into two commands:
``place-call-timegrade'' and ``transfer-timegrade''.  Or maybe another
optional argument to ``timegrade'':
    timegrade grade time-string [retry] [transfer-any]
not to mention
    time time-string [retry] [transfer-any]
Or maybe a separate command for a system or port like
    transfer-any BOOL

190.

Chip Salzenberg: it would be really nice if uucico could automatically
figure out when it could use an E command, so that uux didn't have to
generate it and so that uucico could use with other versions of uux.
Unfortunately, it would require uucico to read the execution file to
see if it were suitable; this would be complex, but it would probably
be worth it since normally the execution file would wind up not being
sent.  Of course, the current method works too; it's just harder to
combine with other versions of UUCP.

191.

Brian J. Murrell: should there be a way to cu a specific alternate?

192.

Andrew A. Chernov: Perhaps cu -pport system should be able to try
different alternates for the system, because there might be different
phone numbers to try.

193.

Brian J. Murrell: it would be nice to be able to ^C a cu chat script
if you know it's going to fail.  Right now you have to use ^\.

194.

Steven S. Dick: have some way to force uucico off the phone at a
certain time.  If that is done, it might be cool to have some way to
predict how long a file transfer will take, and not do it if it will
take too long.  But, if doing file restart, you can just quit and then
pick it up later.

195.

Franc,ois Pinard: if the disk fills up, or some other error occurs,
while receiving a file, perhaps it would make sense to turn the
connection around immediately and see if the other side had anything
to do, and then try again later.  This would require a protocol
extension.  I don't know if it's worth it.  The code should be checked
to see how well it handles a disk full situation.

196.

For real adjustability, provide some mechanism for picking the lead
characters to use for the shell scripts, between : and #!.

197.

Try alternate IP addresses if there are any.

198.

Lele Gaifax: mention the device in Stats, and provide some way to
associate the entry in Log with the entry in Stats.

199.

Michael Richardson: provide some way to turn on parity for the login
chat, since some systems apparently require it.  Provide some way for
cu to control parity after connecting.

200.

Chip Salzenberg: add max-remote-debug to config.

201.

Gert Doering: change the timeout message in chat scripts to reflect
which chat script timed out (dialer or login).

202.

Bill Foote: have uuchk check whether a system is defined more than
once.

203.